Процес розробки програмного забезпечення
| Цикл розробки програмного забезпечення |
|---|
 Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
| Стандарти та галузі знань |
Процес розробки програмного забезпечення (англ. software development process, software process) — сукупність ряду послідовних дій, спрямованих на розробку програмного забезпечення (ПЗ).
Існує кілька моделей такого процесу, кожна з яких описує свій підхід, у вигляді завдань і/або діяльності, які мають місце в ході процесу. Вибір тієї або іншої моделі здійснюється відповідно до обраної методології розробки програмного забезпечення.
Процес розробки складається з безлічі підпроцесів, або дисциплін, деякі з яких показані нижче. У моделі водоспаду вони йдуть одна за одною, в інших аналогічних процесах їх порядок або склад змінюється.
- Аналіз вимог → Специфікація програмного забезпечення
- Проєктування програмного забезпечення
- Програмування
- Тестування програмного забезпечення
- Системна інтеграція
- Впровадження програмного забезпечення (або Установка програмного забезпечення)
- Супровід програмного забезпечення
Водоспадна модель життєвого циклу (англ. waterfall model) була запропонована в 1970 р. Вінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проєкту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, суворо документуються у вигляді технічного завдання і фіксуються на весь час розробки проєкту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Етапи проєкту у відповідності з каскадною моделлю:
- Формування вимог;
- Проєктування;
- Реалізація;
- Тестування;
- Впровадження;
- Експлуатація та супровід.
Переваги
- Повна і погоджена документація на кожному етапі;
- Легко визначити терміни і витрати на проєкт.
Недоліки
У водоспадної моделі перехід від однієї фази проєкту до іншого передбачає повну коректність результату (виходу) попередньої фази. Однак неточність будь-якої вимоги або некоректна його інтерпретація в результаті призводить до того, що доводиться «відкочуватися» до ранньої фази проєкту і необхідна переробка не просто вибиває проєктну команду з графіка, але часто призводить до якісного зростання витрат і, не виключено, до припинення проєкту в тій формі, в якій він спочатку замислювався. На думку сучасних фахівців, основна помилка авторів водоспадної моделі полягає у припущеннях, що проєкт проходить через весь процес один раз, спроєктована архітектура хороша і проста у використанні, проєкт здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені на реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи[1]. Таким чином, водоспадна модель для великих проєктів мало реалістична і може бути ефективно використана тільки для створення невеликих систем[2].
Альтернативою послідовної моделі є так звана модель ітеративної та інкрементальної розробки (англ. iterative and incremental development, IID), отримала також від Т. Ґілба в 1970-ті назву еволюційної моделі. Також цю модель називають ітеративною та інкрементальною моделлю[3].
Модель IID передбачає розбиття життєвого циклу проєкту на послідовність ітерацій, кожна з яких нагадує «міні-проєкт», включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, порівняно з проєктом в цілому. Мета кожної ітерації — отримання версії програмної системи, що працює та включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт отримує приріст — інкремент — до його можливостей, які, отже, розвиваються еволюційно. Ітеративність, інкрементальність і еволюційність в даному випадку є вислів одного і того ж сенсу різними словами зі злегка різних точок зору[2].
За висловом Ґілба, «еволюція — прийом, призначений для створення видимості стабільності. Шанси успішного створення складної системи будуть максимальними, якщо вона реалізується у серії невеликих кроків і якщо кожен крок містить у собі чітко визначений успіх, а також можливість „відкату“ до попереднього успішного етапу в разі невдачі. Перед тим, як пустити в справу всі ресурси, призначені для створення системи, розробник має можливість одержувати з реального світу сигнали зворотного зв'язку і виправляти можливі помилки в проєкті»[3].
Підхід IID має і свої негативні сторони, які, по суті, — зворотній бік чеснот. По-перше, цілісне розуміння можливостей і обмежень проєкту дуже довгий час відсутнє. По-друге, при ітераціях доводиться відкидати частину раніше зробленої роботи. По-третє, сумлінність фахівців при виконанні робіт все ж знижується, що психологічно зрозуміло, адже над ними постійно тяжіє відчуття, що «все одно все можна буде переробити і поліпшити пізніше»[2].
Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки (RUP, MSF, XP).
Спіральна модель (англ. spiral model) була розроблена в середині 1980-х років Баррі Боэмом. Вона заснована на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ЗА створюється в кілька ітерацій (витків спіралі) методом прототипування.
Кожна ітерація відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проєкту, оцінюється якість отриманих результатів і плануються роботи наступної ітерації.
На кожній ітерації оцінюються:
- ризик перевищення строків і вартості проєкту;
- необхідність виконання ще однієї ітерації;
- ступінь повноти і точності розуміння вимог до системи;
- доцільність припинення проєкту.
Важливо розуміти, що спіральна модель є не альтернативою еволюційної моделі (моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно самостійну модель поряд з IID[2].
Відмінною особливістю спіральної моделі є спеціальна увага, що приділяється ризикам, що впливає на організацію життєвого циклу, і контрольним точкам. Боем формулює 10 найбільш поширених (за пріоритетами) ризиків:
- Дефіцит фахівців.
- Нереалістичні терміни і бюджет.
- Реалізація не відповідає функціональності.
- Розробка неправильного користувальницького інтерфейсу.
- Перфекціонізм, непотрібна оптимізація та покращення деталей.
- Безперервний потік змін.
- Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених в інтеграцію.
- Недоліки в роботах, що виконуються зовнішніми (стосовно проєкту) ресурсами.
- Недостатня продуктивність одержуваної системи.
- Розрив у кваліфікації фахівців різних областей.
У сьогоднішній спіральної моделі визначено наступний загальний набір контрольних точок[4]:
- Concept of Operations (COO) — концепція (використання) системи;
- Life Cycle Objectives (LCO) — цілі і зміст життєвого циклу;
- Life Cycle Architecture (LCA) — архітектура життєвого циклу; тут можливо говорити про готовність концептуальної архітектури цільової програмної системи;
- Initial Operational Capability (IOC) — перша версія створюваного продукту, придатна для дослідної експлуатації;
- Final Operational Capability (FOC) — готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.
- ↑ Брукс Ф. Міфічний людино-місяць, або як створюються програмні системи: пер. з англ. / Ф. Брукс. — Санкт-Петербург: Символ-Плюс, 1999. — 304 с.: іл.
- ↑ а б в г Мірошниченко Е. А. Технології програмування: навчальний посібник / Е. А. Мірошниченко. — 2-е изд., испр. і дод. — Томськ: Изд-во Томського політехнічного університету, 2008. — 128 с.
- ↑ а б Ларман К. Ітеративна та інкрементальна розробка: коротка історія [Архівовано 13 жовтня 2016 у Wayback Machine.] / К. Ларман, Ст. Базілю // Відкриті системи. — 2003.
- ↑ Орлик С.